Installation of Certified Software Modules
With the introduction of new generation BSPs, system component updates or application installations can only occur if they are certified via a digital signature performed by the manufacturer. Limiting the installation of software modules to signed modules only is a fundamental security practice that offers numerous advantages. In essence, it ensures that the software installed on your system is authentic, integral, and unmodified by unauthorized third parties.
The new generation of BSPs, starting with versions 2.1.658, 3.1.658, 4.1.658, 5.1.658, 6.0.x, and 7.0.x, contain the manufacturer's certificate required to verify the signature of subsequent updates.
The HMI device owner must install their own certificate on the device to be able to certify the applications they want to install or distribute.
Signed file
To install or update a software module, you'll also need to provide the module's signature file.
The file containing the module's signature is a two-line ASCII file. The first line contains the MD5 hash of the file, while the second line holds the module's signature performed by the manufacturer.
User Certificate
If you don't own a certificate to sign your applications for upload to the device, you can create one using OpenSSL.
Here is an example of how to generate a certificate using a public OpenSSL-Win32 library (https://www.openssl.org).
File: CreateCertificates.cmd
@echo off set OpenSSL="C:\Program Files\OpenSSL-Win64\bin\openssl.exe" set CertificateName=MyCertificate rem Generate an RSA key %OpenSSL% genrsa -out private_key.pem 4096 rem Creating Certificate Signing Requests %OpenSSL% req -new -sha256 -key private_key.pem -out certificate.csr -subj "/ST=NY/C=US/L=New York/O=CompanyName/OU=R&D Team/CN=%CertificateName%" rem Self Sign the Certificate Signing Requests %OpenSSL% x509 -req -days 365 -in certificate.csr -signkey private_key.pem -out certificate.crt rem Convert to .pfx file %OpenSSL% pkcs12 -export -passout pass:PswOfCertificate -out certificate.pfx -inkey private_key.pem -in certificate.crt -CSP "Microsoft Enhanced RSA and AES Cryptographic Provider" pause
The procedure will require creating a password, which will then be necessary to access the certificate's private key (in the example script, the password "PswOfCertificate" has been defined).
Two files will be generated:
- certificate.pfx is the certificate containing the private key to install on your PC to sign code. You'll need the certificate's password to install it
- certificate.crt is the certificate containing the public key that must be installed on the HMI device so it can verify the signature
- private_key.pem It's the file with the private key associated with the certificate that can be used to sign your applications. It's crucial not to disclose this key to avoid invalidating the encryption process..
How to install the certificate on the HMI device
On the HMI device the certificate.crt can be installed from the System Settings of the HMI device in the Security area (Ref. "Security").
In the Security area, select:
- Domain = Public
- Secret ID = App Certificate
- Type = Certificate
- Use the "Update" button to load the certificate
Script to sign a file
Here is an example of how to sign the application file to be installed on the HMI device.
File: Signing.cmd
@echo off set OpenSSL="C:\Program Files\OpenSSL-Win64\bin\openssl.exe" set FileName=MyApplication.zip rem Generate the MD5 file certUtil -hashfile %FileName% MD5 | find /v "hash" > md5.tmp rem Sign the MD5 file %OpenSSL% dgst -sha256 -sign private_key.pem -out %FileName%.sig.tmp %FileName% CertUtil -encodehex %FileName%.sig.tmp encoded.tmp 12 > nul rem Merge MD5 and sign copy /b md5.tmp+encoded.tmp %FileName%.sig > nul rem Delete the MD5 file del *.tmp echo Done pause
A new file with a .sig extension will be generated:
- MyApplication.zip.sig It's the file with the application's signature to be used for installing the application.
Signature of USB tools
Applications run from a USB drive will also need to be signed. In addition to the tool itself, a file named "manifest.json" must be included on the USB drive, containing the signature for each file belonging to the tool. The "manifest.json" file itself must also be signed.
Here is an example of a manifest file.
File: manifest.json
e9fb94c6176cf9ce8417b3aad8860165a62987941d9dc8d5a8d64e51b { "name": "USBUpdater", "version": "2.8", "files": [ { "path": "autoexec.sh", "signature": "4d56b441af6d84259872b69e27bdc18ce051b3a7a4bd776db8250a240" }, { "path": "src/usbupdater", "signature": "f98216f1d1637859f142861837e1f823287e5560766d57bd5cb9b25eb" }, { "path": "src/config", "signature": "3bb5be8db0000eb5484e0a15a97e008493f07e409b08091e903440546" } ] }
The first line contains the signature of the manifest.json file, while the file itself lists the tool's files with their signatures.
Here's how to prepare a manifest.json file, step by step
- Create a text file without the first line, meaning the text contained between the two curly braces (here you need to include one or more files).
- Using the "Signing.cmd" script, generate the signatures for each file.
- Copy each file's signature (the second line of the file generated by the "Signing.cmd" script) into the "signature" field of its respective file descriptor.
- Use the "Signing.cmd" script to generate the signature for the "manifest.json" file.
- Insert the "manifest.json" file's signature (the second line of the generated signature) into the first line of the file.
Guideline
With the new BSPs, applications can only be installed if they are certified (i.e., signed by the developer). Therefore, the application developer needs to obtain their own certificate to sign the applications they intend to distribute or install on the device.
The certificate essentially consists of two keys: a secret key (which must not be disclosed) that allows the developer to sign the application, certifying it was developed by its owner, and a public key to be installed on devices, which allows for verification of the signature's authenticity.
After installing the public key on the devices, the developer can generate their application and distribute it along with the file containing its signature to install it on the HMI devices.
Certificate Verification
The certificate used to validate BSP updates is located in the /usr/share/platform-keys
folder on the HMI device and is distributed/updated along with firmware updates. To validate its integrity, you need to verify its fingerprint (contained within the certificate) by comparing it with the fingerprint published by Exor International S.p.A..
Date | Fingerprint | Status |
---|---|---|
18/Jun/2025 | 11dffefde555a9d02a3bee70ba29c973b9f07241 | Valid |
Allow installation of unsigned modules (Compatible Mode)
Signature verification can be disabled, however, this is an unrecommended operating mode that you shouldn't use unless you're fully aware of what you're doing.
System Settings -> Security -> Software Components
For compatibility reasons, BSPs v2.1 and v3.1 will be distributed with signature verification disabled, while BSPs v4.1, v5.1, v6.0, v7.0, etc. will have signature verification enabled by default.